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Abstract 

We  describe  a  shared  ontology  called  SOUPA  -  Stan¬ 
dard  Ontology  for  Ubiquitous  and  Pervasive  Applications. 
SOUPA  is  designed  to  model  and  support  pervasive  comput¬ 
ing  applications.  This  ontology  is  expressed  using  the  Web 
Ontology  Language  OWL  and  includes  modular  component 
vocabularies  to  represent  intelligent  agents  with  associated 
beliefs,  desires,  and  intentions,  time,  space,  events,  user 
profiles,  actions,  and  policies  for  security  and  privacy.  We 
discuss  how  SOUPA  can  be  extended  and  used  to  support 
the  applications  of  CoBrA,  a  broker-centric  agent  archi¬ 
tecture  for  building  smart  meeting  rooms,  and  MoGATU,  a 
peer-to-peer  data  management  for  pervasive  environments. 


1.  Introduction 

Pervasive  computing  is  a  natural  extension  of  the  exist¬ 
ing  computing  paradigm.  In  the  pervasive  computing  vision, 
computer  systems  will  seamlessly  integrate  into  the  life  of 
everyday  users,  providing  them  with  services  and  informa¬ 
tion  in  an  “anywhere,  anytime”  fashion.  We  believe  in  this 
open  and  dynamic  environment,  intelligent  computing  enti¬ 
ties  must  be  able  to  share  knowledge,  reason  about  their  en¬ 
vironment,  and  interoperate. 

In  the  past,  many  prototyping  systems  and  architec¬ 
tures  have  successfully  demonstrated  aspects  of  the  perva¬ 
sive  computing  paradigm,  e.g.,  handheld  devices  are  aug¬ 
mented  with  context-aware  applications  to  create  personal¬ 
ized  tour  guides  for  the  museum  visitors  [1,  18],  the  user  in¬ 
terfaces  and  applications  on  a  resource-poor  mobile  device 
can  dynamically  migrate  to  a  nearby  resource-rich  station¬ 
ary  computer  when  the  user  enters  the  office  [3],  and  sys¬ 
tems  can  route  telephone  calls  to  the  present  location  of  a 
user  by  tracking  the  location  of  an  electronic  badge  that  the 
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user  wears  [31].  However,  they  offer  only  weak  support  for 
knowledge  sharing  and  reasoning. 

A  significant  source  of  this  weakness  is  that  they  are  not 
built  on  a  foundation  of  common  ontologies  with  explicit 
semantic  representation  [9,  13].  For  example,  the  location 
information  of  a  user  is  widely  used  for  guiding  the  adaptive 
behavior  of  the  systems  [27,  32,  29].  However,  none  have 
taken  advantageous  of  the  semantics  of  spatial  relations  in 
reasoning  about  the  location  context  of  the  users.  Addition¬ 
ally,  many  systems  use  programming  language  objects  (e.g., 
Java  class  objects)  to  represent  the  knowledge  that  the  com¬ 
puter  systems  have  about  the  situational  environment.  Be¬ 
cause  these  representations  require  the  establishment  of  a 
prior  low-level  implementation  agreement  between  the  pro¬ 
grams  that  wish  to  share  information,  they  cannot  facilitate 
knowledge  sharing  in  an  open  and  dynamic  environment. 

To  address  these  issues,  we  believe  a  shared  ontology 
must  be  developed  for  supporting  knowledge  sharing,  con¬ 
text  reasoning  and  interoperability  in  ubiquitous  and  per¬ 
vasive  computing  systems.  By  defining  such  ontology,  we 
can  help  system  developers  to  reduce  their  efforts  in  creat¬ 
ing  ontologies  and  to  be  more  focused  on  the  actual  system 
implementations . 

In  this  paper,  we  describe  a  shared  ontology  for  support¬ 
ing  pervasive  computing  applications.  This  ontology  called 
SOUPA  -  Standard  Ontology  for  Ubiquitous  and  Perva¬ 
sive  Applications  is  expressed  using  the  Web  Ontology  Lan¬ 
guage  OWL  and  includes  modular  component  vocabularies 
to  represent  intelligent  agents  with  associated  beliefs,  de¬ 
sires,  and  intentions,  time,  space,  events,  user  profiles,  ac¬ 
tions,  and  policies  for  security  and  privacy. 

The  rest  of  this  paper  is  organized  as  follows.  In  Section 
2,  we  overview  the  OWL  language  and  other  related  ontolo¬ 
gies.  In  Section  3,  we  describe  SOUPA  and  its  ontological 
structure.  In  Section  4,  we  discuss  how  SOUPA  can  be  ex¬ 
tended  and  used  to  support  two  different  pervasive  comput¬ 
ing  scenarios.  One  is  in  the  context-aware  smart  meeting 
domain  based  on  CoBrA  [8],  and  the  other  is  in  the  peer- 
to-peer  data  management  domain  based  on  MoGATU  [25]. 
Conclusions  are  given  in  Section  5. 
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2.  Background 

The  SOUPA  project  begins  in  November  2003  and  is 
part  of  an  ongoing  effort  of  the  Semantic  Web  in  Ubi- 
Comp  Special  Interest  Group1,  an  international  group  of  re¬ 
searchers  from  academia  and  industry  that  is  using  the  OWL 
language  for  pervasive  computing  applications  and  defin¬ 
ing  ontology-driven  use  cases  demonstrating  aspects  of  the 
ubiquitous  computing  vision. 

The  goal  of  the  project  is  to  define  ontologies  for  sup¬ 
porting  pervasive  computing  applications.  The  design  of 
SOUPA  is  driven  by  a  set  of  use  cases.  While  the  SOUPA 
vocabularies  overlaps  with  the  vocabularies  of  some  exist¬ 
ing  ontologies,  the  merits  of  SOUPA  is  in  providing  per¬ 
vasive  computing  developers  a  shared  ontology  that  com¬ 
bines  many  useful  vocabularies  from  different  consensus 
ontologies.  We  believe  SOUPA  can  help  developers  who 
are  inexperience  in  knowledge  representation  to  quickly  be¬ 
gin  building  ontology-driven  applications  without  needing 
to  define  ontologies  from  scratch,  and  they  can  focus  more 
on  the  functionalities  of  the  actual  system  implementations. 

2.1.  The  Web  Ontology  Language  OWL 

The  OWL  language  is  a  Semantic  Web  language  for  use 
by  computer  applications  that  need  to  process  the  content 
of  information  instead  of  just  presenting  information  to  hu¬ 
mans  [20].  This  language  is  developed  in  part  of  the  Seman¬ 
tic  Web  initiatives  sponsored  by  the  World  Wide  Web  Con¬ 
sortium  (W3C). 

The  current  human-centered  web  is  largely  encoded  in 
HTML,  which  focuses  largely  on  how  text  and  images 
would  be  rendered  for  human  viewing.  Over  the  past  few 
years  we  have  seen  a  rapid  increase  in  the  use  of  XML  as  an 
alternative  encoding,  one  that  is  intended  primarily  for  ma¬ 
chine  processing.  The  machine  which  process  XML  docu¬ 
ments  can  be  the  end  consumers  of  the  information,  or  they 
can  be  used  to  transform  the  information  into  a  form  appro¬ 
priate  for  human  understand  (e.g.,  as  HTML,  graphics,  and 
synthesized  speech).  As  a  representation  language,  XML 
provides  essentially  a  mechanism  to  declare  and  use  sim¬ 
ple  data  structures,  and  thus  it  leaves  much  to  be  desired 
as  a  language  for  expressing  complex  knowledge.  Enhance¬ 
ments  to  the  basic  XML,  such  as  XML  Schemas,  address 
some  of  the  shortcomings,  but  still  do  not  result  in  an  ad¬ 
equate  language  for  representing  and  reasoning  about  the 
kind  of  knowledge  essential  to  realizing  the  Semantic  Web 
vision. 

OWL  is  a  knowledge  representation  language  for  defin¬ 
ing  and  instantiating  ontologies.  An  ontology  is  a  formal 
explicit  description  of  concepts  in  a  domain  of  discourse 
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(or  classes),  properties  of  each  class  describing  various  fea¬ 
tures  and  attributes  of  the  class,  and  restrictions  on  proper¬ 
ties  [21], 

The  normative  OWL  exchange  syntax  is  RDF/XML. 
Ontologies  expressed  in  OWL  are  usually  placed  on  web 
servers  as  web  documents,  which  can  be  referenced  by  other 
ontologies  and  downloaded  by  applications  that  use  ontolo¬ 
gies.  In  this  paper,  we  refer  to  these  web  documents  as  the 
ontology  documents. 

2.2.  Related  Ontologies 

Part  of  the  SOUPA  vocabularies  are  adopted  from  a  num¬ 
ber  of  different  consensus  ontologies.  The  strategy  for  de¬ 
veloping  SOUPA  is  to  borrow  terms  from  these  ontolo¬ 
gies  but  not  to  import  them  directly.  Although  the  seman¬ 
tics  for  importing  ontologies  is  well  defined  [2],  by  choos¬ 
ing  not  to  use  this  approach  we  can  effectively  limit  the 
overhead  in  requiring  reasoning  engines  to  import  ontolo¬ 
gies  that  may  be  irrelevant  to  pervasive  computing  applica¬ 
tions.  However,  in  order  to  allow  better  interoperability  be¬ 
tween  the  SOUPA  applications  and  other  ontology  applica¬ 
tions,  many  borrowed  terms  in  SOUPA  are  mapped  to  the 
foreign  ontology  terms  using  the  standard  OWL  ontology 
mapping  constructs  (e.g.,  owl :  equivalentClass  and 
owl :  equivalentProperty). 

The  ontologies  that  are  referenced  by  SOUPA  include 
the  Friend-Of-A-Friend  ontology  (FOAF)  [5,  26],  DAML- 
Time  and  the  entry  sub-ontology  of  time  [22],  the  spatial 
ontologies  in  OpenCyc  [19],  Regional  Connection  Calcu¬ 
lus  (RCC)  [28],  COBRA-ONT  [7],  MoGATU  BDI  ontol¬ 
ogy  [23],  and  the  Rei  policy  ontology  [15].  In  the  rest  of 
this  section,  we  describe  the  key  features  of  these  related 
ontologies  and  point  out  their  relevance  to  pervasive  com¬ 
puting  applications. 

FOAF  This  ontology  allows  the  expression  of  personal  in¬ 
formation  and  relationships,  and  is  a  useful  building  block 
for  creating  information  systems  that  support  online  com¬ 
munities  [12],  Pervasive  computing  applications  can  use 
FOAF  ontologies  to  express  and  reason  about  a  person’s 
contact  profile  and  social  connections  to  other  people  in 
their  close  vicinity. 

DAML-Time  &  the  Entry  Sub-ontology  of  Time  The  vo¬ 
cabularies  of  these  ontologies  are  designed  for  expressing 
temporal  concepts  and  properties  common  to  any  formal¬ 
ization  of  time.  Pervasive  computing  applications  can  use 
these  ontologies  to  share  a  common  representation  of  time 
and  to  reason  about  the  temporal  orders  of  different  events. 

OpenCyc  Spatial  Ontologies  &  RCC  The  OpenCyc  spa¬ 
tial  ontologies  define  a  comprehensive  set  of  vocabularies 
for  symbolic  representation  of  space.  The  ontology  of  RCC 
consists  of  vocabularies  for  expressing  spatial  relations  for 


Figure  1.  SOUPA  consists  of  two  sets  of  ontology  documents:  SOUPA  Core  and  SOUPA  Extension. 
The  OWL  owl :  imports  construct  is  used  to  enable  a  modular  design  of  the  ontology.  Different  do¬ 
main  vocabularies  are  grouped  under  different  XML  namespaces. 


qualitative  spatial  reasoning.  In  pervasive  computing  appli¬ 
cations,  these  ontologies  can  be  exploited  for  describing  and 
reasoning  about  location  and  location  context  [7]. 

COBRA-ONT  &  MoGATU  BDI  Ontology  Both 
COBRA-ONT  and  MoGATU  BDI  ontology  are  aimed  for 
supporting  knowledge  representation  and  ontology  reason¬ 
ing  in  pervasive  computing  environment.  While  the  de¬ 
sign  of  COBRA-ONT  focuses  on  modeling  contexts  in 
smart  meeting  rooms  [7],  the  design  of  MoGATU  BDI  on¬ 
tology  focuses  on  modeling  the  belief,  desire,  and  intention 
of  human  users  and  software  agents  [23], 

Rei  Policy  Ontology  The  Rei  policy  language  defines  a  set 
of  deontic  concepts  (i.e.,  rights,  prohibitions,  obligations, 
and  dispensations)  for  specifying  and  reasoning  about  se¬ 
curity  access  control  rules.  In  a  pervasive  computing  envi¬ 
ronment,  users  can  use  this  policy  ontology  to  specify  high- 
level  rules  for  granting  and  revoking  the  access  rights  to  and 
from  different  services  [16]. 

3.  SOUPA  Ontologies 

SOUPA  consists  of  two  distinctive  but  related  set  of  on¬ 
tologies:  SOUPA  Core  and  SOUPA  Extension.  The  set  of 


the  SOUPA  Core  ontologies  attempts  to  define  generic  vo¬ 
cabularies  that  are  universal  for  different  pervasive  comput¬ 
ing  applications.  The  set  of  SOUPA  Extension  ontologies, 
extended  from  the  core  ontologies,  define  additional  vocab¬ 
ularies  for  supporting  specific  types  of  applications  and  pro¬ 
vide  examples  for  the  future  ontology  extensions. 

Note  that  the  structure  of  the  ontology  merely  suggests 
certain  vocabularies  are  more  general  than  the  others  in  sup¬ 
porting  pervasive  computing  applications,  and  there  is  no 
inherent  computational  complexity  difference  in  adopting 
either  set  of  the  ontologies. 

3.1.  SOUPA  Core 

This  set  of  ontologies  consists  of  vocabularies  for  ex¬ 
pressing  concepts  that  are  associated  with  person,  agent, 
belief-desire-intention  (BDI),  action,  policy,  time,  space, 
and  event.  The  ontologies  are  grouped  into  nine  distinctive 
ontology  documents.  Figure  1  shows  a  diagram  of  the  on¬ 
tology  documents  and  their  associated  relations. 

3.1.1.  Person  This  ontology  defines  typical  vocabularies 
for  describing  the  contact  information  and  the  profile  of  a 
person.  The  OWL  class  per :  Person  is  defined  to  repre¬ 
sent  a  set  of  all  people  in  the  SOUPA  domain,  and  is  equiva- 


lent  to  the  f  oaf :  Person  class  in  the  FOAF  ontology  (i.e., 
the  owl :  equivalentClass  property  holds  between  the 
per: Person  and  foaf: Person  class).  An  individual 
of  the  class  can  be  described  by  a  set  of  properties,  which 
include  basic  profile  information  (name,  gender,  age,  birth 
date,  etc.),  the  contact  information  (email,  mailing  address, 
homepage,  phone  numbers,  instant  messaging  chat  ID,  etc.), 
and  social  and  professional  profile  (people  that  a  person  is 
friend  of,  organizations  that  a  person  belongs  to).  In  addi¬ 
tion,  all  property  vocabularies  that  are  applicable  to  describe 
a  person  in  the  FOAF  ontology  can  also  be  used  to  describe 
an  individual  of  the  per:  Person  class.  This  is  because 
all  individuals  of  the  per  :  Person  class  are  also  individ¬ 
uals  of  the  foaf :  Person  class.  The  following  shows  a 
partial  ontology  description  of  the  person  Harry  Chen: 

<per : Person> 

<per : f irstName 

rdf : datatype="&xsd; string>Harry</per : f irstName> 

<per : lastName 

rdf : datatype="&xsd; string>Chen</per : lastName> 

<per : gender  rdf : resource=" &per; Male" /> 

<per : birthDate 

rdf : datatype="&xsd; date ">197 6-12-2 6</per :birthDate> 
<per : homepage 

rdf : resource="http : //umbc.edu/people/hchen4"/> 

<foaf : weblog 

rdf : resource="http : //umbc.edu/people/hchen4"/> 

<per : hasSchoolContact  rdf : resource="#SchoolContact "/> 
<per : hasHomeContact  rdf : resource="#HomeContact "/> 

<foaf : workplaceHomepage 

rdf : resource="http : //ebiquity .umbc . edu"/> 

<foaf : workplaceHomepage 

rdf : resource="http : //www . umbc . edu"/> 

<foaf : workplaceHomepage 

rdf : resource="http : //www. cs .umbc.edu"/> 

</per : Person> 

<per : ContactProf ile  rdf : ID="SchoolContact "> 

<per : address  rdf : datatype="&xsd; string"> 

Dept,  of  CSEE,  UMBC,  1000  Hilltop  Circle, 

Baltimore,  MD  21250,  USA 
</per : address> 

<per : phone 

rdf : datatype="&xsd; string> 

+1-410-455-8648 
</per :phone> 

<per : email 

rdf : resource="mailto : harry . chen@umbc . edu"/> 

<per : im 

rdf : resource="aim:goim?screenname=hcl379"/> 

</per : ContactProf ile> 

<per : Email  rdf : about="mailto : harry . chenQumbc . edu" /> 

<per : Homepage  rdf : about="http : / /www. aim. com"/> 

<per : Chat ID  rdf : about="aim: goim?screenname=hcl379"> 

<per : providedBy  rdf : resource="http : //www. aim. com" /> 
</per : ChatID> 

<per : ContactProf ile  rdf : ID="HomeContact "> 

</per : ContactProf ile> 

<f oaf : knows> 

<foaf : Person> 

<f oaf : name>Tim  Finin</f oaf : name> 

<foaf :mbox_shalsum> 

49953. . . 148d37 
</foaf :mbox_shalsum> 

</f oaf : Person> 


</f oaf : knows> 

</ rdf : RDF> 

3.1.2.  Policy  &  Action  Security  and  privacy  are  two 
growing  concerns  in  developing  and  deploying  pervasive 
computing  systems  [6,  17,  13].  Policy  is  an  emerging  tech¬ 
nique  for  controlling  and  adjusting  the  low-level  system  be¬ 
haviors  by  specifying  high-level  rules  [11], 

The  SOUPA  policy  ontology  defines  vocabularies  for 
representing  security  and  privacy  policies  and  a  descrip¬ 
tion  logic  based  mechanism  for  reasoning  about  the  defined 
policies.  The  defined  vocabularies  in  this  ontology  are  in¬ 
fluenced  by  the  Rei  policy  language  [15], 

A  policy  is  a  set  of  rules  that  is  specified  by  a  user  or 
a  computing  entity  to  restrict  or  guide  the  execution  of  ac¬ 
tions.  For  example,  in  the  context  of  system  security,  a  sys¬ 
tem  administrator  may  use  policies  to  define  who  has  the 
right  to  execute  what  services;  in  the  context  privacy  pro¬ 
tection,  a  user  may  use  policies  to  restrict  the  type  of  per¬ 
sonal  information  that  can  be  shared  by  the  public  services. 

The  ontology  representation  of  an  action  is  defined  in  the 
action  ontology  document.  The  class  act :  Action  rep¬ 
resents  a  set  of  all  actions.  Individuals  of  this  class  can  have 
a  set  of  property  values,  which  include  (i)  act :  actor  - 
the  entity  that  performs  the  action,  (ii)  act :  recipient 
-  the  entity  that  receives  the  effect  after  the  action  is  per¬ 
formed,  (iii)  act :  target  -  the  object  that  the  action  ap¬ 
plies  to,  (iv)  act :  location  -  the  location  at  where  the 
action  is  performed,  (v)  act :  time  -  the  time  at  which  the 
action  is  performed,  (vi)  act :  instrument  -  the  thing 
that  the  actor  uses  to  perform  the  action. 

The  following  shows  a  partial  ontology  that  defines  a 
special  class  of  knowledge  sharing  action: 

cowl : Class  rdf : ID="ShareHarryLocInfoWithEBMembers"> 
cowl : intersectionOf  rdf :parseType="Collection"> 
cowl :Class  rdf :about="&act; Action"/> 

cowl : Restriction> 

cowl : onProperty  rdf : resource="&act; actor"> 
cowl : hasValue> 

cagt : Agent  rdf : about="ctb@cobral . cs . umbc . edu" /> 
c/owl : hasValue> 
c/owl : Restriction> 

cowl : Restriction> 

cowl : onProperty  rdf : resource="&act; target"/> 
c/owl : allvaluesFrom 

rdf : resource=" #LocationContextOf Harry " /> 
c/owl : Restriction> 

cowl : Restriction> 

cowl : onProperty  rdf : resource="&act ; recipient "/> 
cowl : allvaluesFrom 

rdf : resource=" &eb; EbiquityMembers"/> 
c/owl : Restriction> 
c/owl : intersectionOf > 
c/owl : Class> 

cowl : Class  rdf : ID="LocationContextOfHarry "> 

cowl : intersectionOf  rdf :parseType="Collection"> 
cowl : Class  rdf : about="&loc; LocationContext "/> 
cowl : Restriction> 
cowl : onProperty 

rdf : resource="&loc : locationContextOf " /> 
cowl : hasValue> 


<per : Person 

rdf : about="http : / /umbc . edu/people/hchen4 " /> 
</ owl : hasValue> 

</Restriction> 

</owl : intersectionOf > 

</owl : Class> 

The  above  example  describes  a  set  of  actions  of  which 
the  actor  is  the  agent  ctbScobral .  cs  .  umbc  .  edu,  the 
recipient  is  any  member  of  the  eBiquity  group,  the  target, 
or  the  information  to  be  shared,  is  Harry’s  location  infor¬ 
mation. 

In  SOUPA,  a  policy  consists  of  rules  that  either  permit  or 
forbid  the  execution  of  certain  described  actions.  Defined  in 
the  policy  ontology  document,  the  pol : Policy  class 
represents  a  set  of  all  policies.  For  a  given  policy  individ¬ 
ual,  it  may  be  associated  with  one  or  more  pol :  permits 
or  pol :  forbids  properties.  The  range  of  these  two  prop¬ 
erties  are  the  pol  :PermittedAction  class  and  the 
pol :  ForbiddenAction  class,  respectively. 

The  following  example  shows  a  policy  that  gives  the 
agent  ctb@cobral.cs.umbc.edu  the  permission  to 
share  Harry’s  location  information  with  all  eBiquity  mem¬ 
bers: 

<pol : Policy  rdf : about =" & cobra; harrychen-policy "> 

<pol :policyOf> 

<per : Person 

rdf : about="http : / /umbc . edu/people/hchen4 "> 

<per : name 

rdf : datatype="&xsd; string">Harry  Chen</per : name> 
</per : Person> 

</pol :policyOf> 

<pol : def aultPolicyMode 

rdf : resour ce=" &pol; Requi re sExplicit Permission " /> 

<pol : permits 

rdf : resource=" #ShareHarryLocInf oWithEBMembers" /> 

</pol : Policy> 

The  policy  ontology  also  defines  vocabularies  for 
describing  meta  information  about  individual  poli¬ 
cies.  This  information  includes  the  author  of  a  pol¬ 
icy  (pol :  creator),  the  entity  that  enforces  a  pol¬ 
icy  (pol :  enforcer),  the  creation  time  of  a  policy 
(pol :  createdOn),  and  the  default  reasoning  mode  of  a 
policy  (pol :  defaultPolicyMode). 

The  design  of  the  SOUPA  policy  exploits  classification 
as  a  means  to  reason  about  policies.  A  typical  process  flow 
of  the  system  implementation  is  the  following:  (i)  a  user 
or  a  system  administrator  defines  a  policy,  (ii)  the  policy 
is  transmitted  to  the  appropriate  policy  enforcer  (e.g,  a  se¬ 
curity  or  a  privacy  protection  agent),  (iii)  before  the  pol¬ 
icy  enforcer  can  permit  other  agents  to  perform  an  action, 
it  creates  an  explicit  representation  of  the  action  using  the 
SOUPA  action  ontology,  (iv)  this  represented  action  is  then 
loaded  into  a  description  logic  reasoner  (e.g..  Racer  [14]  or 
FaCT2)  along  with  the  associated  ontology,  (v)  the  policy 


2  http : / / www .  cs . man . ac . uk/ ~ ho r rocks /FaCT/ 


enforcer  will  permit  the  execution  of  the  action  if  the  action 
is  classified  as  type  of  pol :  PermittedAction,  and  it 
will  forbid  the  execution  of  the  action  if  the  action  is  classi¬ 
fied  as  type  of  pol :  ForbiddenAction. 

In  case  if  an  input  action  is  classified  as  both 
pol : PermittedAction  and  pol : Forbidden¬ 
Action,  then  the  policy  enforcer  will  report  there  is  an 
inconsistency  in  the  policy  and  may  forbid  the  execu¬ 
tion  of  the  action  by  default.  In  case  if  the  action  can¬ 
not  be  classified  as  either  classes,  the  policy  enforcer  will 
decide  whether  the  action  should  be  permitted  or  for¬ 
bidden  based  on  the  default  policy  mode  (see  the  above 
example).  If  the  mode  is  pol :  RequiresExplicit- 
Permission,  then  the  action  will  be  forbidden.  If  the 
mode  is  pol :  RequiresNoExplicitPermission, 
then  the  action  will  be  permitted. 

3.1.3.  Agent  &  BDI  When  building  intelligent  pervasive 
computing  systems,  sometimes  it  is  useful  to  model  com¬ 
puting  entities  as  agents  [33].  In  SOUPA,  agents  are  defined 
with  a  strong  notion  of  agency  [33],  which  is  characterized 
by  a  set  of  mentalistic  notions  such  as  knowledge,  belief,  in¬ 
tention,  and  obligation.  In  this  ontology,  both  computational 
entities  and  human  users  can  be  modeled  as  agents. 

When  the  goals,  plans,  desires,  and  beliefs  of  different 
agents  are  explicitly  represented  in  the  ontologies,  this  in¬ 
formation  can  help  independently  developed  agents  to  share 
a  common  understanding  of  their  “mental”  states,  help¬ 
ing  them  to  cooperate  and  collaborate.  The  explicitly  rep¬ 
resented  human  user’s  mental  states  can  help  computing 
agents  to  reason  about  the  specific  needs  of  the  users  in  a 
pervasive  environment. 

Two  ontology  documents  are  related  to  this  ontology: 
agent  and  bdi.  The  agt :  Agent  class  represents  a 
set  of  all  agents  in  the  SOUPA  domain  and  is  associated 
with  three  properties  that  can  be  used  to  characterize  an 
agent’s  “mental”  state:  agt :  believes,  agt :  desires, 
and  agt:  intends.  The  respective  range  values  of 
these  properties  are  the  bdi: Fact,  bdi: Desire,  and 
bdi  :  Intention  classes.  The  goals  of  an  agent  are  con¬ 
sidered  to  be  a  special  type  of  desire,  which  is  expressed  by 
defining  the  agt :  hasGoal  property  as  a  sub-property  of 
the  agt :  desires  property. 

The  bdi:  Fact  class  is  a  subclass  of  the 
rdf :  Statement  class,  which  represents  a  set  of 
reified  RDF  statements  [4].  A  reified  RDF  statement 
consists  of  the  rdf:  subject,  rdf:  object,  and 
rdf :  predicate  properties. 

The  bdi  :  De  s  i  r  e  class  defines  a  set  of  world  states  that 
agents  desire  to  bring  about.  Every  instances  of  this  class 
can  be  characterized  by  the  property  bdi  :  endState.  The 
range  restriction  of  this  property  is  unspecified  in  the  bdi 
ontology  document.  Application  developers  are  responsi¬ 
ble  for  defining  the  representation  of  different  world  states. 


Some  suggested  representations  are  (i)  symbolic  names, 
e.g.,  a  set  of  pre-defined  RDF  resource  URI  and  (ii)  meta¬ 
representation,  e.g.,  each  world  state  description  is  a  set  of 
reified  RDF  statements. 

The  bdi  :  Intention  class  represents  a  set  of  plans 
that  agents  intend  to  execute.  Plans  are  defined  in  terms  of 
actions,  pre-conditions,  and  effects.  The  bdi  :Plan  class 
is  defined  as  a  subclass  of  the  act:Action  class  with 
additional  properties,  namely  bdi:preCondition  and 
bdi  :  effect. The  representation  of  pre-conditions  and  ef¬ 
fects  are  unspecified  in  this  ontology,  and  it  is  left  to  be  de¬ 
fined  by  the  application  ontologies. 

Sometimes  it  may  be  useful  to  describe  whether  or  not 
different  desires  of  an  agent  are  in  conflict  of  each  other, 
and  whether  or  not  certain  desires  are  achievable.  The  cause 
of  desire  conflicts  may  be  due  to  inconsistent  beliefs  in 
the  knowledge  base  or  conflicting  user  preferences  or  sys¬ 
tems  policies.  The  cause  of  unachievable  desires  may  be 
due  to  the  change  of  situational  conditions.  In  the  bdi  on¬ 
tology  document,  different  subclasses  of  the  bdi  :  Desire 
class,  bdi  :  Conf  lictingDesire,  bdi:Non- 

Conf lictingDesire,  bdi : AchievableDesire, 
and  bdi  :  UnachievableDesire,  are  defined  for  clas¬ 
sifying  different  types  of  agent  desires. 

3.1.4.  Time  SOUPA  defines  a  set  of  ontologies  for  ex¬ 
pressing  time  and  temporal  relations.  They  can  be  used  to 
describe  the  temporal  properties  of  different  events  that  oc¬ 
cur  in  the  physical  world. 

Part  of  the  SOUPA  ontology  adopts  the  vocabularies  of 
the  DAML-time  and  the  entry  sub-ontology  of  time.  The 
basic  representation  of  time  consists  of  the  tme  :  Time- 
Instant  and  tme  :  Timelnterval  classes.  All  individ¬ 
ual  members  of  these  two  classes  are  also  members  of  the 
tme :  TemporalEntity  class,  which  is  an  OWL  class 
that  is  defined  by  taking  the  union  of  the  tme :  Time- 
Instant  and  tme  :  Timelnterval  classes.  The  set  of 
all  temporal  things  that  are  divided  into  two  disjoint  classes: 
tme  :  Instant  Thing,  things  with  temporal  descriptions 
that  are  type  of  time  instant,  and  tme :  Interval- 
Thing,  things  with  temporal  descriptions  that  are  type  of 
time  interval.  The  union  of  these  two  classes  forms  the 
tme :  TemporalThing  class. 

In  order  to  associate  temporal  things  with  date/time  val¬ 
ues  (i.e.,  their  temporal  descriptions),  the  tme  :  at  property 
is  defined  to  associate  an  instance  of  the  tme  :  Instant- 
Thing  with  an  XML  xsd:dateTime  datatype  value 
(e.g.,  2004-12-25T12:32:12),  and  the  tme:  from  and 
tme: to  properties  are  defined  to  associate  an  instance 
of  the  IntervalThing  with  two  different  tme  :  Time- 
Instant  individuals.  The  following  example  shows  the 
representation  of  a  time  interval  with  the  associated  tempo¬ 
ral  description: 

<tme : Timelnterval> 


<tme : f rom> 

<tme : Timelnstant> 

<tme : at  rdf : datatype="xsd; dateTime"> 
2004-02-01T12:01:01 
</tme : at> 

</tme : Timelnstant> 

</tme : f rom> 

<tme : to> 

<tme : Timelnstant> 

<tme : at  rdf : datatype="xsd; dateTime"> 
2004-02-llT13:41:21 
</tme : at> 

</tme : Timelnstant> 

</tme : to> 

</tme : Timelnterval> 

For  describing  the  order  relations  between  two  differ¬ 
ent  time  instants,  the  ontology  defines  the  following  prop¬ 
erties:  tme: before,  tme: after,  tme : bef oreOr- 
At,  tme  :  afterOrAt,  and  tme  :  sameTimeAs.  Both 
tme  :  before  and  tme  :  after  properties  are  defined  of 
type  owl : TransitiveProperty.  The  tme: same¬ 
TimeAs  property  expresses  that  two  different  time  instants 
are  associated  with  equivalent  date/time  values  and  is  de¬ 
fined  of  type  owl :  SymmetricProperty. 

For  describing  the  order  relations  between  two  dif¬ 
ferent  temporal  things  (i.e.,  time  instants  and  time  in¬ 
tervals),  the  ontology  defines  the  following  properties: 
tme : startsSoonerThan,  tme : startsLater- 
Than,  tme :  startsSameTimeAs,  tme:ends- 
SoonerThan,  tme : endsLaterThan,  tme:ends- 
SameTimeAs,  tme :  startsAfterEndOf,  and 
tme  :  endsBef  oreStartOf.  The  first  three  proper¬ 
ties  respectively  express  that  for  any  two  given  temporal 
things  A  and  B,  the  starting  time  of  A  is  before  the  start¬ 
ing  time  of  B,  the  starting  time  of  A  is  after  the  starting 
time  of  B,  and  the  starting  time  of  A  is  the  same  as  the  start¬ 
ing  time  of  B.  The  next  three  properties  respectively  express 
that  for  any  two  given  temporal  things  A  and  B,  the  end¬ 
ing  time  of  A  is  before  the  ending  time  of  B,  the  ending  time 
of  A  is  after  the  ending  time  of  B,  and  the  ending  time  of  A 
is  the  same  as  the  ending  time  of  B.  The  tme :  starts¬ 
AfterEndOf  property  expresses  that  the  beginning  of 
one  temporal  thing  is  after  the  ending  of  another  tempo¬ 
ral  thing,  and  the  tme  :  endsBef  oreStartOf  property 
expresses  the  inverse  of  this  property. 

In  the  future  we  plan  to  extend  this  ontology  to  adopt 
or  map  to  additional  vocabularies  from  the  RDF  Calendar 
ontologies3  for  modeling  time  intervals  that  may  contain 
repeating  time  intervals  or  instants.  This  new  feature  will 
be  useful  for  representing  recurrent  events  such  as  weekly 
meetings  and  classes. 

3.1.5.  Space  This  ontology  is  designed  to  support  reason¬ 
ing  about  the  spatial  relations  between  various  types  of  geo¬ 
graphical  regions,  mapping  from  the  geo-spatial  coordinates 
to  the  symbolic  representation  of  space  and  vice  versa,  and 


3  http://www.w3.org/2002/12/cal/ 


the  representation  of  geographical  measurements  of  space. 
Part  of  this  ontology  vocabularies  are  adopted  from  the  spa¬ 
tial  ontology  in  OpenCyc  and  the  OpenGIS  vocabularies 
[10]. 

Two  ontology  documents  are  related  to  this  ontology: 
space  and  geo-measurement.  The  first  ontology  doc¬ 
ument  defines  a  symbolic  representation  of  space  and  spa¬ 
tial  relations,  and  the  second  document  defines  typical  geo¬ 
spatial  vocabularies  (e.g.,  longitude,  latitude,  altitude,  dis¬ 
tance,  and  surface  area). 

In  the  symbolic  representation  model,  the  spc :  Spa- 
tialThing  class  represents  a  set  of  all  things  that  have 
spatial  extensions  in  the  SOUPA  domain.  All  spatial  things 
that  are  typically  found  in  maps  or  construction  blueprints 
are  called  spc  :  Geographical  Space.  This  class  is  de¬ 
fined  as  the  union  of  the  spc  :  GeographicalRegion, 
spc :  FixedStructure,  and  spc  :  SpacelnAFixed- 
Structure  classes. 

An  individual  member  of  the  spc :  Geographical- 
Region  class  typically  represents  a  geographical  region 
that  is  controlled  by  some  political  body  (e.g.,  the  coun¬ 
try  US  is  controlled  by  the  US  government).  This  relation  is 
expressed  by  the  spc  :  controls  property,  the  domain  of 
which  is  spc  :  GeopoliticalEntity  and  the  range  of 
which  is  spc  :  GeographicalRegion.  Knowing  which 
political  entity  controls  a  particular  geographical  region,  a 
pervasive  computing  system  can  choose  to  apply  the  appro¬ 
priate  policies  defined  by  the  political  entity  to  guide  its  be¬ 
havior.  For  example,  a  system  may  apply  different  sets  of 
privacy  protection  schemes  based  on  the  policies  defined  by 
the  local  political  entities. 

To  support  spatial  containment  reasoning,  individual 
members  of  the  spec  :  GeographicalSpace  class  can 
relate  to  each  other  through  the  spc :  spatially- 
Subsumes  and  spc :  spatial lySubsumedBy  proper¬ 
ties.  For  example,  a  country  region  may  spatially  subsumes 
a  state  region,  a  state  region  may  spatially  subsumes  a  build¬ 
ing,  and  a  building  may  spatially  subsumes  a  room.  Know¬ 
ing  the  room  in  which  a  device  is  located,  we  can  infer  the 
building,  the  state  and  the  country  that  spatially  subsumes 
the  room. 

In  the  geo-spatial  representation  model,  the  individ¬ 
ual  members  of  the  spc :  SpatialThing  class  are 
described  by  location  coordinates  (i.e.,  longitude,  lati¬ 
tude,  and  altitude).  This  relation  is  expressed  by  the 
spc :  hasCoordinates  property,  the  range  of  which  is 
the  geo  :  LocationCoordinates  class.  In  this  model, 
multiple  location  coordinates  can  be  mapped  to  a  single  ge¬ 
ographical  region  (e.g.,  a  university  campus  typically  cov¬ 
ers  multiple  location  coordinates.).  This  relation  is  useful 
for  defining  spatial  mapping  between  different  geograph¬ 
ical  locations  and  GPS  coordinates.  This  information  can 
enable  a  GPS-enabled  device  to  query  the  symbolic  repre¬ 


sentation  of  its  present  location  for  a  given  set  of  longitude, 
latitude,  and  altitude. 

3.1.6.  Event  Events  are  event  activities  that  have  both  spa¬ 
tial  and  temporal  extensions.  An  event  ontology  can  be  used 
to  describe  the  occurrence  of  different  activities,  schedules, 
and  sensing  events.  In  the  event  ontology  document,  the 
eve  :  Event  class  represents  a  set  of  all  events  in  the  do¬ 
main.  However,  the  definition  of  this  class  is  silent  about  its 
temporal  and  spatial  properties. 

The  eve  :  SpatialTemporalThing  class  repre¬ 
sents  a  set  of  things  that  have  both  spatial  and  tem¬ 
poral  extensions,  and  it  is  defined  as  the  intersection 
of  the  tme  :  TemporalThing  and  spc:  Spatial¬ 
Thing  classes.  To  specifically  describe  events  that  have 
both  temporal  and  spatial  extensions,  eve:Spatial- 
TemporalEvent  class  is  defined  as  the  intersection  of 
the  eve : SpatialTemporalThing  and  eve: Event 
classes. 

The  following  example  shows  how  the  ontology  can  be 
used  to  describe  an  event  in  which  a  Bluetooth  device  has 
been  detected  on  2004-02-01  at  12:01:01  UTC,  and  the 
event  occurs  at  a  location  that  is  described  by  longitude  - 
76.71 13  and  latitude  39.2524: 

cowl : Class  rdf : ID="DetectedBluetoothDev"> 

<rdf s : subClassOf 

rdf : resource=" &eve; TemporalSpatialEvent " /> 

</owl : Class> 

cowl : Ob jectProperty  rdf : ID=" foundDevice"> 
crdf s : domain 

rdf : resource="#DetectedBluetoothDev"/> 
c/owl  :0b jectProperty> 

cDetectedBluetoothDev> 
cspc : hasCoordinates> 

cgeo : LocationCoordinates> 

cgeo : longitude  rdf : datatype . . . > 

-76.7113 

c/geo : longitude> 

cgeom: latitude  rdf : datatype ... > 

39.2524 

c/geom: latitude> 
c/geo : LocationCoordinates> 
c/spc : hasCoordinates> 

cf oundDevice  rdf : resource="url-x-some-device" /> 

ctme : at> 

ctme : Timelnstant> 

ctme : at  rdf : datatype="xsd; dateTime"> 
2004-02-01T12:01:01 
c/tme : at> 

c/tme : Timelnstant> 
c/tme : at> 

cDetectedBluetoothDev> 

3.2.  SOUPA  Extension 

The  SOUPA  Extension  ontologies  are  defined  with  two 
purposes:  (i)  define  an  extended  set  of  vocabularies  for  sup¬ 
porting  specific  types  pervasive  application  domains,  and 
(ii)  demonstrate  how  to  define  new  ontologies  by  extending 
the  SOUPA  Core  ontologies.  At  present,  the  SOUPA  Exten¬ 
sion  consists  of  experimental  ontologies  for  supporting  per- 


vasive  context-aware  applications  in  smart  spaces  and  peer- 
to-peer  data  management  in  a  pervasive  computing  environ¬ 
ment.  Due  to  space  limitation,  in  this  section,  we  briefly  de¬ 
scribe  the  existing  SOUPA  Extension  ontologies. 

Meeting  &  Schedule  For  describing  typical  information 
associated  with  meetings,  event  schedules,  and  event  par¬ 
ticipants. 

Document  &  Digital  Document  For  describing  meta¬ 
information  about  documents  and  digital  documents,  e.g., 
the  creation  date  and  the  author  of  a  document,  the  source 
URL  of  a  digital  document,  file  size,  and  file  type. 

Image  Capture  When  a  camera  phone  takes  a  picture,  this 
event  is  type  of  image  capturing  event.  This  ontology  de¬ 
fines  vocabularies  for  describing  image  capturing  events 
(where  and  when  a  picture  is  taken,  which  device  has  taken 
the  picture,  etc.). 

Region  Connection  Calculus  A  spatial  ontology  that  sup¬ 
plements  the  core  space  ontology.  Based  on  the  Region 
Connection  Calculus  [28],  this  ontology  defines  vocabular¬ 
ies  for  expressing  spatial  relations  for  qualitative  spatial  rea¬ 
soning. 

Location  For  describing  sensed  location  context  of  a  per¬ 
son  or  an  object.  The  location  context  is  information  that 
describes  the  whereabouts  of  a  person  or  an  object,  which 
includes  both  temporal  and  spatial  properties. 

4.  SOUPA  Applications 

To  demonstrate  SOUPA  is  feasible  for  supporting  per¬ 
vasive  computing  applications,  we  are  prototyping  two  use 
case  scenarios.  One  is  in  the  pervasive  context-aware  meet¬ 
ing  room  domain  based  on  CoBrA,  and  the  other  is  in  the 
peer-to-peer  data  management  domain  based  on  MoGATU. 
Our  objective  is  to  show  that  by  defining  a  shared  perva¬ 
sive  computing  ontology,  we  can  help  system  developers  to 
reduce  their  efforts  in  creating  ontologies  and  to  be  more  fo¬ 
cused  on  the  actual  implementation  of  their  systems. 

4.1.  CoBrA 

CoBrA  is  a  broker-centric  agent  architecture  for  support¬ 
ing  context-aware  systems  in  smart  spaces  [8],  Central  to 
the  architecture  is  the  presence  of  a  Context  Broker,  an  in¬ 
telligent  agent  that  runs  on  a  resource-rich  stationary  com¬ 
puter  in  the  space.  It’s  responsible  for  acquiring  and  main¬ 
taining  context  knowledge,  reasoning  about  the  information 
that  cannot  be  directly  acquired  from  sensors  (e.g.,  inten¬ 
tions,  roles,  temporal  and  spatial  relations),  detecting  and 
resolving  inconsistent  knowledge  that  is  stored  in  the  shared 
model  of  context,  and  protecting  user  privacy  by  enforcing 


policies.  CoBrA  has  been  used  to  prototype  a  smart  meet¬ 
ing  system  called  EasyMeeting  [9],  in  which  the  Context 
Broker  uses  ontologies  and  logic  inference  rules  to  reason 
about  the  location  of  meeting  attendees  based  on  the  loca¬ 
tion  of  their  personal  Bluetooth  cellphones,  and  share  this 
information  with  other  meeting  services  in  the  conference 
room. 

The  SOUPA  ontologies  can  be  used  in  CoBrA  to  facil¬ 
itate  knowledge  sharing  and  ontology  reasoning.  The  fol¬ 
lowing  use  case  describes  typical  uses  of  the  ontologies  in 
CoBrA: 

Room  338  is  a  smart  meeting  room.  On  March  8th,  2004, 
a  presentation  is  scheduled  to  take  place  from  1:00-2:30  PM 
in  this  room.  Moments  before  the  event  starts,  the  room’s 
Context  Broker  acquires  the  meeting’s  schedule  from  the 
Web,  which  is  expressed  in  the  schedule  ontology,  and 
concludes  the  meeting  is  about  to  take  place  in  the  Room 
338.  As  the  meeting  participants  begin  to  arrive,  the  room’s 
Bluetooth  Sensing  Agent  detects  the  presences  of  differ¬ 
ent  Bluetooth  enabled  devices  (e.g.,  cellphones,  PDA’s).  Be¬ 
cause  each  device  has  a  unique  device  owner  profile,  which 
is  expressed  in  the  person  ontology,  the  sensing  agent  can 
share  this  information  with  the  Context  Broker. 

Based  on  the  acquired  information  (e.g.,  what  type  of  de¬ 
vice  it  is,  and  who  owns  what  devices)  and  without  know¬ 
ing  any  evidence  to  the  contrary,  the  Context  Broker  con¬ 
cludes  the  owners  of  the  detected  devices  are  also  located 
in  the  Room  338.  Among  the  arrived  participants,  Harry 
the  speaker  and  President  Hrabowski  the  distinguished  au¬ 
dience  are  two  people  that  are  listed  in  the  meeting  sched¬ 
ule.  This  information  is  expressed  in  the  meeting  and  the 
schedule  ontologies.  The  Context  Broker  shares  their  lo¬ 
cation  information,  which  is  expressed  in  the  space  and 
time  ontologies,  with  the  subscribed  Meeting  Manage¬ 
ment  Agent. 

Knowing  that  President  Hrabowski  has  a  distinguished 
audience  role,  the  Meeting  Management  Agent  invokes  a 
greeting  service  to  greet  him.  At  1 :00  PM,  the  Context  Bro¬ 
ker  informs  the  the  same  agent  that  all  listed  key  participants 
have  arrived  and  that  the  presentation  can  start.  Knowing  all 
the  lights  in  the  meeting  are  currently  switched  on  and  the 
background  music  is  also  playing,  the  agent  tells  the  light 
controller  to  dim  the  lights  and  the  music  service  to  stop  the 
music. 

4.2.  MoGATU 

MoGATU  is  a  framework  for  handling  pro-active  peer- 
to-peer  semantic  data  management  in  a  pervasive  comput¬ 
ing  environment  [24,  25].  The  framework  treats  all  devices 
present  in  the  environment  as  equal  semi-autonomous  peers. 
To  provide  uniformed  communication  functionality  and  to 
handle  data  management  issues,  this  framework  abstracts 


all  devices  in  the  environment  as  a  collection  of  Infor¬ 
mation  Managers,  Information  Providers,  and  Information 
Consumers.  It  specifies  several  communication  interfaces 
for  supporting  ad-hoc  IEEE  802.11  and  Bluetooth  like  net¬ 
works.  Each  InforMa  is  responsible  for  maintaining  infor¬ 
mation  about  peers  in  its  vicinity.  This  information  includes 
the  types  of  devices,  and  information  and  services  they  pro¬ 
vide.  An  InforMa  also  maintains  a  data  cache  for  storing  in¬ 
formation  obtained  from  other  mobile  devices  and  to  cache 
information  generated  by  its  local  Providers.  Additionally, 
each  InforMa  may  include  a  user’s  profile  reflecting  some 
of  user’s  beliefs,  desires,  and  intentions,  a  model  adopted 
by  the  SOUPA  ontology.  MoGATU  is  targeted  toward  per¬ 
vasive  environments,  which  invert  the  traditional  sense  of 
data  management  in  distributed  databases  that  is  based  on 
“passive  data”  and  “active  users”  concepts  [30]. 

A  key  use  of  the  SOUPA  ontologies  in  MoGATU  is  to  ex¬ 
press  beliefs,  preferences,  intentions,  and  desires  of  an  agent 
or  a  user,  and  the  priority  values  of  plans  and  goals.  The  fol¬ 
lowing  use  case  describes  typical  uses  of  the  ontologies  in 
MoGATU: 

While  Bob  is  getting  ready  to  leave  his  new  office,  his 
phone  rings.  It  is  his  new  friend  Jane  asking  him  to  meet 
her  at  the  local  shopping  mall.  Bob  agrees  to  meet  her  and 
notifies  his  palmtop  about  the  decision.  While  he  is  walk¬ 
ing  through  the  building  toward  the  parking  lot  and  ulti¬ 
mately  toward  his  car,  the  palmtop  fetches  appropriate  di¬ 
rections  from  the  web  through  the  office  network  infras¬ 
tructure.  Once  inside  a  car,  the  palmtop  speaks  out  the  direc¬ 
tions  and  Bob  follows  them;  however,  the  device  knows  that 
Bob  has  a  time  constraint  when  he  should  meet  Jane.  It  ac- 
tivelly  queries  cars  around  Bob,  to  ask  them  if  there  is  any 
traffic  delay  on  the  selected  route,  and  if  they  know  of  an  al¬ 
ternate,  faster  route.  It  turns  out  that  there  is  a  traffic  jam 
building  up  on  the  route,  that  was  suggested  by  the  web  ser¬ 
vice  and  that  also  would  be  planned  by  Bob’s  car  naviga¬ 
tional  system.  The  palmtop,  therefore,  queries  surrounding 
cars  and  is  able  to  return  with  an  alternate  set  of  directions 
that  circumvent  the  afternoon  traffic  jam.  Bob  takes  the  dif¬ 
ferent  roads  and  is  able  to  arrive  at  the  mail’s  entrance  thirty 
minutes  early. 

Bob  decides  to  use  the  extra  time  to  check  out  local 
stores.  His  palmtop  learns  from  the  shopping  mall  broker 
that  it  is  now  located  inside  the  mall.  The  palmtop  pro¬ 
actively  evaluates  all  intentions  and  desires  of  Bob,  stored 
in  his  profile,  to  see  if  it  can  assist  Bob  in  satisfying  some  of 
them.  It  infers  that  Bob  needs  a  new  pair  of  shoes.  Accord¬ 
ingly,  it  starts  to  query  available  shoe  stores  for  their  cur¬ 
rent  offers  and  also  tries  to  negotiate  addidional  deals.  As 
Bob  walks  through  the  mall,  the  palmtop  is  able  to  collect 
enough  evidence  store  advertisements  and  other  customers’ 
opinions  on  stores  and  their  offerings.  The  palmtop  com¬ 
bines  the  collected  knowledge  and  suggests  Bob  to  visit  the 


shoe  store  in  Nordstrom.  This  is  because  the  palmtop  was 
able  to  negotiate  a  20%  sale  coupon  on  Bob’s  favorite  shoe 
brand.  Bob  decides  to  use  the  offer  and  purchases  a  pair  of 
shoes.  The  palmtop  learns  that  from  Bob’s  credit  card  state¬ 
ment  and  removes  the  associated  goal.  Consequently,  upon 
next  visit  of  the  mall,  the  palmtop  will  no  longer  place  a 
high  priority  on  obtaining  deals  from  shoe  stores. 

5.  Conclusions 

The  use  of  ontologies  is  a  key  requirement  for  realizing 
the  vision  of  pervasive  computing.  We  believe  by  defining 
a  shared  pervasive  computing  ontology,  we  can  help  system 
developers  to  reduce  their  efforts  in  creating  ontologies  and 
to  be  more  focused  on  the  actual  system  implementations. 
The  SOUPA  project  is  a  step  towards  the  standardization  of 
a  shared  ontology  for  ubiquitous  and  pervasive  computing 
applications. 

We  believe  SOUPA  will  evolve  as  the  pervasive  com¬ 
puting  research  progresses.  The  use  of  SOUPA  shows  great 
promises  in  facilitating  knowledge  sharing  and  ontology 
reasoning  in  both  CoBrA  and  MoGATU.  We  expect  the  vo¬ 
cabularies  and  the  structures  of  SOUPA  to  change  when  the 
research  community  becomes  more  experienced  in  develop¬ 
ing  ontology-driven  applications. 

The  overall  experience  in  developing  the  SOUPA  ontol¬ 
ogy  was  challenging.  First,  when  building  a  shared  ontol¬ 
ogy  that  is  aimed  to  reuse  a  number  of  different  ontologies, 
it  was  difficult  to  decide  what  is  the  most  appropriate  ontol¬ 
ogy  structure  for  organizing  the  defined  vocabularies.  Sec¬ 
ond,  because  not  all  of  the  reused  ontologies  were  devel¬ 
oped  using  the  same  ontology  language,  and  some  of  which 
were  developed  to  support  different  types  of  logic  infer¬ 
ences,  often  it  was  necessary  to  modify  the  structures  and 
the  constructs  of  the  existing  ontologies  before  including 
them  into  the  SOUPA  ontology.  Third,  developing  method¬ 
ologies  to  measure  the  success  of  the  SOUPA  ontology  was 
difficult. 

In  the  current  SOUPA  ontology  development  process,  we 
have  taken  the  following  approaches  to  address  the  above 
three  issues:  (i)  we  have  developed  use  case  scenarios  with 
functional  specifications  to  help  us  decide  the  appropriate 
structures  for  organizing  ontological  vocabularies,  (ii)  we 
have  chosen  the  OWL  DL  sub-language  as  the  language  to 
build  a  shared  ontology  from  the  existing  ontologies,  (iii) 
we  plan  to  show  the  usefulness  of  the  SOUPA  ontology  by 
prototyping  different  pervasive  computing  systems  to  use 
SOUPA. 
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